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SUMMARY 


The  rapid  growth  In  the  use  of  microcomputer-based  systems  for  functions  ranging  frow 
•dal nl strati ve  support  through  operations  aids  has  led  to  Air  Force  concerns  about  coaiputer 
proliferation.  A  nuaber  of  near-future  acquisitions  Involve  systems  designed  for  training.  As 
It  now  stands,  these  systeas  will  each  Involve  Independent  design,  acquisition,  logistics,  and 
aalntenance  support.  A  possible  solution  to  this  problea  Is  to  consolidate  requirements  In  order 
to  produce  a  coaaon  computer-based  training  (CBT)  system  that  could  be  adapted  as  needed  to 
specific  user  requirements.  This  paper  proposes  an  approach  similar  to  that  used  in  the  Z-150 
acquisition,  thereby  providing  a  vehicle  for  speeding  acquisition  and  allowing  widespread 
logistics  support  without  legislating  that  It  be  the  only  system  used.  The  advantages  of  such  an 
approach  Include  the  cost  benefits  of  a  large  buy,  reduced  development  time  for  new  applications, 
facilitation  of  logistics  support,  encouragement  of  Industry  standardization,  and 
transportability  of  courseware/software  across  systems.  Some  of  the  core  hardware/software 
capabilities  to  be  Incorporated  Into  such  a  system  Include:  (a)  substantial  computational 
capability  and  memory  capacity,  (b)  advanced  graphics,  (c)  videodisc  Interface,  (d)  sophisticated 
software  development  tools,  (e)  optional  user  Interfaces,  and  (f)  networking.  Future 
considerations,  such  as  artificial  Intelligence  applications,  enhanced  authoring  capabilities, 
and  simulator  Interfaces  are  also  discussed. 


PREFACE 


This  effort  represents  a  portion  of  the  research  and  development  (RAO)  program  of 
the  Air  Force  Human  Resources  Laboratory  (AFHRL)  for  Technical  Planning  Objective  3.  the 
thrust  of  which  Is  Aircrew  Training.  The  general  objective  of  this  thrust  Is  to 
Identify  and  demonstrate  cost  effectiveness  In  training  Air  Force  aircrew  members.  This 
paper  was  completed  In  response  to  a  HQ  USAF  request  to  consider  the  design  of  a  common 
computer-based  system  for  aircrew  training.  It  Is  being  published  with  the  hope  of 
gaining  a  wider  audience  for  consideration  of  these  Issues. 

The  authors  would  like  to  acknowledge  the  contributions  of  several  Individuals 
whose  Ideas  and  comments  helped  to  refine  the  approach  recommended  herein.  They  are  Lt 
Cols  Bill  Baltazar  and  Jim  Colle.  HQ  USAF/XOOTH;  Lt  Col  Mike  Dickinson.  AFHRL/ ID;  and 
Ors.  Bernle  Edwards  and  Bob  Nul lawyer.  AFHRL /OT. 
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COMMON  COMPUTER-BASED  TRAINING  SYSTEM: 
A  RECOMMENDED  APPROACH 


I.  INTRODUCTION 


Background 

The  Air  Force  Is  currently  faced  with  the  Issue  of  prol Iferatlon  of  Microcomputer-based 
systems.  These  systems  are  being  acquired  for  a  variety  of  applications,  which  run  the  gamut 
from  administrative  support  through  operational  aids.  Many  of  the  near-future  acquisitions 
Involve  systems  designed  for  training.  As  It  now  stands,  each  of  these  systems  will  require 
Independent  design,  acquisition,  logistics,  and  maintenance  support.  For  the  Individual 
operational  squadron,  this  will  result  In  a  multiplicity  of  small  computers,  each  with  Its  own 
operating  characteristics.  Interface  requirements,  and  support  network.  Unless  steps  are  taken 
to  alleviate  the  situation,  the  Individual  squadron  member  will  be  required  to  have  computer 
expertise  on  a  variety  of  systems,  and  the  squadron  as  a  whole  will  have  to  cope  with  the 
maintenance  problems  associated  with  them.  In  addition  to  the  problem  of  computer  proliferation, 
there  Is  pressure  on  the  Air  Force  to  develop  a  policy  for  computer-based  training  (CBT) 
systems.  This  pressure  Is  the  result  of  direction  from  Congress  to  the  Department  of  Defense 
(DOO).  If  the  Air  Force  does  not  develop  such  a  policy,  one  may  be  Imposed  by  flat. 

A  possible  approach  to  the  Issue  of  proliferation,  particularly  for  CBT,  Is  the  concept  of  a 
common  system.  "Common*  In  this  case  Implies  the  design  of  a  system  to  fulfill  multiple 
requirements,  rather  than  to  meet  only  a  specific  application.  Such  a  system  could  be  made 
available  on  a  continuing  contract,  reducing  response  times  for  the  development  of  new  training 
applications  that  It  can  support.  It  should  be  stressed  that  such  a  system  would  not  be  levied 
as  a  requirement  for  all  CBT  applications.  Its  use  would  be  determined  by  the  particular 
training  requirements  Involved.  There  are  also  some  measures  that  could  be  taken  to  make  other 
C8T  application  systems  more  compatible.  Prior  to  a  discussion  of  the  proposed  approach,  a 
general  philosophy  concerning  CBT  will  be  discussed. 


CBT  Philosophy 

As  with  the  emergence  of  previous  training  technologies,  CBT  has  been  hailed  by  many  as  the 
"solution"  to  our  training  problems  (Clark,  1983).  As  with  sound/sllde  or  videotape,  initially 
there  has  been  great  enthusiasm,  which  will  no  doubt  be  followed  by  some  dlsgruntlement 
concerning  the  difficulty  of  actually  applying  the  technology.  In  fact,  a  considerable  number  of 
attempts  to  apply  CBT  to  date  have  used  It  as  a  replacement  for  classroom  or  academic 
Instruction.  In  such  cases,  the  computer  basically  replaces  the  textbook  as  a  source  of 
information.  This  "page-turner"  application  of  CBT  takes  minimum  advantage  of  the  capabilities 
that  CBT  provides.  If  the  computer  serves  only  as  a  replacement  for  a  textbook,  it  is  not  a 
cost-effective  solution.  Instead,  the  Instructional  applications  of  CBT  should  take  advantage  of 
the  unique  capabilities  of  the  computer  Itself,  such  as  graphics,  real-time  Interactivity,  the 
flexibility  to  support  multiple  tasks,  and  the  ability  to  support  individually  paced  Instruction. 

Three  areas  where  the  computer  provides  unique  opportunities  are  in  real-time  task 
simulation,  performance  measurement/scoring,  and  true  computer-assisted/computer-managed 
Instruction  (CA2/CMI)  (Edwards,  In  press).  Real-time  task  simulation  allows  the  student  in 
Initial  training  to  get  "on-task"  as  early  as  feasible  in  the  Instructional  sequence,  without  the 
need  for  costly  actual  equipment  trainers.  In  addition,  this  type  of  simulation  has  even  greater 
applicability  to  operational  training,  where  the  trainee  is  already  familiar  with  the  basic  task 
and  simply  requires  practice  In  a  variety  of  situations/conditions.  Numerous  studies  have 


documented  the  relative  equivalence  of  computer-based  and  actual  equipment  training  (Babbitt, 
Pleper,  Semple,  i  Swanson,  1985).  Performance  measurement/scoring  serves  two  functions.  First, 
It  provides  feedback  to  the  student  concerning  task  performance,  allowing  him/her  to  compare  to  a 
standard,  observe  Improvements  with  practice,  etc.  Such  feedback  Is  essential  If  learning  Is  to 
occur  (Salmonl,  Schmidt,  &  Halter,  1984).  Hell -designee1  feedback  can  be  motivational  as  well  as 
diagnostic.  Second,  performance  measurement/scoring  allows  the  system  to  adjust  the  level  of  the 
task  to  the  capabilities  of  the  student.  This  takes  us  Into  the  realm  of  CAI/CMI,  where  the 
pacing  of  Instruction  and  the  types  of  cues/feedback  provided  to  the  student  are  driven  by  the 
student's  capabilities.  This  Is  a  depature  from  the  lock-step  nature  of  classroom  Instruction, 
where  everyone  must  proceed  at  a  common  pace.  Performance  measurement/scoring  also  plays  a  role 
In  CMI,  where  scheduling  of  training  resources  (Including  the  computer)  Is  based  on  student 
progress/performance. 

Given  these  considerations.  It  Is  clear  that  any  CBT  system  should  provide  some  capability 
for  task  simulation  and  performance  measurement.  The  complexity  of  the  tasks  simulated  and  the 
degree  of  CAI/CMI  Incorporated  Into  the  system  drive  the  level  of  sophistication  of  the 
hardware/software  required.  At  one  end  of  the  spectrum  are  devices  that  are  primarily 
page- turners ,  with  limited  task  simulation  and  requiring  only  limited  graphics  capability.  At 
the  other  end  of  the  spectrum  are  systems  which  are  graphics-intensive,  with  the  emphasis  on 
complex  task  simulation. 

The  fact  that  such  a  broad  spectrum  of  applications  exists  implies  that  any  coimnon  CBT  system 
will.  In  fact,  need  to  be  a  family  of  systems.  Some  applications  will  not  require  the 
sophistication  of  a  high-capability  graphics  system,  and  It  would  not  be  cost  effective  to  use 
such  a  system  In  such  cases.  There  should  Instead  be  some  core  hardware/software  requirements 
which  can  serve  as  a  building  block  for  more  or  less  sophisticated  systems,  depending  on  the 
training  needs.  The  core  requirements  would  ensure  compatibility  and  transportability  to  some 
degree  throughout  the  spectrum  of  systems.  In  this  way,  courseware  could  be  adapted  for  the  more 
simple  applications  or  for  more  sophisticated  systems  as  needed. 

As  should  already  be  apparent,  the  types  of  systems  being  discussed  here  are 
microcomputer-based,  with  little  or  no  operational  hardware.  This  excludes  "part-task  trainers" 
such  as  the  Air  Refueling  Part-Task  Trainer  or  the  Boom  Operator  Part-Task  Trainer,  which  are 
actually  crew  station  simulators  for  specific  tasks.  The  systems  under  consideration  here 
provide  Interactive  training  using  computer-generated  and/or  videodisc  displays,  with  student 
input  via  various  Interface  devices  (e.g.,  touch  screen,  joystick,  mouse).  In  some  cases,  actual 
hardware  may  be  Interfaced  with  the  system,  such  as  an  aircraft  control  stick,  to  increase  the 
fidelity  of  Interaction,  but  the  majority  of  the  system  is  not  specific  to  a  particular  weapon 
system.  This  fact  constitutes  the  basis  for  the  possibility  of  a  common  CBT  system.  Such  a 
system  could  support  multiple  training  tasks  via  use  of  various  software  packages  and  (in  some 
cases)  individualized  user  Interfaces.  The  system  would  need  to  be  modular,  as  discussed 
previously,  to  adapt  its  sophistication  to  a  specific  application.  However,  such  an  approach  is 
not  well  suited  to  existing  acquisition  policies,  where  only  the  minimum  capability  is  acquired 
for  each  Individual  application.  The  possibilities  offered  by  the  Z-150  acquisition  approach 
would  appear  to  provide  an  attractive  alternative.  If  an  appropriately  configured  family  of  CBT 
systems  could  be  designed,  this  approach  would  allow  users  to  apply  the  system  as  needed  to  their 
training  requirements  without  going  through  the  full-scale  development  and  acquisition  process. 
This  process  now  takes  approximately  5  years,  and  leads  to  problems  in  acquiring  state-of-the-art 
systems  that  are  supportable  within  the  rapidly  changing  computer  Industry. 

Clearly,  this  common  CBT  system  would  need  to  be  designed  for  training  per  se.  It  is 
essential  to  avoid  having  a  system  that  is  designed  solely  for  other  applications  (e.g., 
data/word  processing)  designated  as  "the"  training  system.  Although  such  systems  are  capable  of 
performing  many  tasks,  they  do  not  necessarily  have  the  features  desirable  in  a  training 


system.  On  the  other  hand,  a  system  designed  for  training  may  have  many  of  the  features 
desirable  In  operational  alos,  and  so  It  may  be  possible  to  use  the  same  set  of  hardware  for 
those  applications. 


11.  APPROACH 


Proposed  Approach 

The  general  approach  recommended  here,  as  mentioned  above.  Is  to  use  the  Z-150  acquisition  as 
a  model  for  the  development  of  a  contract  for  a  cannon  CBT  system,  designed  In  advance  to  suit  a 
variety  of  training  needs.  Based  on  the  Identification  of  training  requirements,  users  would  be 
able  to  order  the  appropriate  number  of  systems,  configured  to  meet  their  needs,  through  an 
existing  contract.  A  maintenance  contract  would  also  exist  to  provloe  parts  and  service  through 
a  large-scale  network,  be  believe  this  approach  is  feasible  due  to  two  factors.  First, 
state-of-the-art  microcomputers  have  reached  the  point  where  their  capabilities  rival  those  of 
minicomputers  or  even  mainframe  computers.  This  allows  the  use  of  the  substantial  memory  and 
central  processing  unit  (CPU)  capacity  required  for  supporting  complex  task  simulations  ana 
significant  CAI/CMI  functions.  Second,  our  experience  with  part-task  trainer  development  and 
evaluation  has  suggested  some  of  the  capabilities  we  feel  are  necessary  In  such  a  common  system. 
If  It  Is  to  support  a  wide  range  of  training  tasks.  Clearly,  any  such  contract  would  have  to 
incorporate  provisions  for  advances  in  the  state  of  the  art,  by  builaing  In  growth  potential  and 
incorporating  enhancements  Into  newly  delivered  systems  where  it  is  cost  effective  to  do  so.  The 
contract  should  also  be  limited  to  some  prespecified  period  In  recognition  of  the  rapid  advances 
In  computer  technology  which  Improve  the  state  of  the  art.  The  use  of  such  a  contractual 
approach  has  a  number  of  advantages  that  will  be  discussed  in  the  next  section.  However,  there 
are  two  alternative  approaches  which  deserve  comment. 

One  alternative  to  the  proposed  approach  would  be  to  require  everyone  using  CBT  to  use  a  core 
set  of  hardware.  This  would  have  the  advantage  of  reducing  logistics  problems,  while  ensuring 
substantial  compatibility  and  transportability  of  courseware.  However,  such  an  approach  would 
require  that  all  possible  applications  of  CBT  be  Identified  In  advance  so  that  the  appropriate 
capabilities  could  be  designed  In.  This  Is  nearly  Impossible  to  Imagine.  In  addition,  such  an 
approach  would  lock  the  Air  Force  into  a  single  manufacturer,  with  the  attendant  problems  of 
production  delays,  sole-source  buys,  etc.  It  may  also  not  be  cost  effective  to  always  require 
the  training  developer  to  use  a  common  system.  In  the  case  of  total  contracted  training.  It  may 
be  much  more  effective  to  allow  the  contractor  to  determine  which  type  of  CBT  system  best  suits 
the  overall  design  ana  Is  compatible  with  other  facets  of  the  training  system.  Given  these  and 
other  considerations,  we  do  not  believe  that  this  Is  a  viable  approach. 

A  second  alternative  would  be  to  simply  establish  functional  standards  for  all  CBT  systems, 
In  an  attempt  to  Increase  compatibility  and  transportability  of  courseware.  Such  standards  might 
involve  use  of  a  32-bit  CPU  to  support  complex  applications,  sufficient  memory  to  take  advantage 
of  sophisticated  software  development  tools,  standard  user  interfaces,  etc.  Unfortunately, 
although  we  believe  some  standards  are  appropriate,  It  does  not  appear  that  this  approach  is  very 
practical.  The  primary  problem  is  In  the  graphics  arena.  There  Is  simply  no  conmon  graphics 
language  In  the  industry.  This  means  that  graphics  developed  on  one  system  would  have  to  be 
converted  to  run  on  any  other  system.  It  may  be  wise  for  the  Air  Force  to  encourage  industry 
standardization  in  this  area;  however,  at  least  initially,  selection  of  any  particular  graphics 
language  would  essentially  Imply  sole-source  hardware,  with  the  attendant  problems  mentioned 
above. 

Due  to  the  problems  with  these  alternatives,  the  proposed  approach  attempts  a  compromise 
between  them.  It  does  not  require  all  CBT  users  to  adapt  to  a  single  system  but  rather,  provides 
them  a  vehicle  for  what  we  hope  Is  a  more  responsive  acquisition  to  meet  their  needs.  It  still 


provides  the  flexibility  to  use  alternative  systems,  where  cost  or  time  or  other  considerations 
make  such  systems  more  appropriate.  On  the  other  hand,  it  goes  beyono  purely  functional 
standards  in  that  it  assures  compatibility  and  transportability  for  those  who  use  the  coamon 
system.  It  will  also  facilitate  logistics  support.  This  leads  us  Into  the  advantages  and 
disadvantages  of  such  a  common  system,  to  which  we  now  turn. 


Advantages/Disadvantages 

There  are  a  number  of  advantages  to  the  common  CbT  approach.  First,  there  is  the  cost 
advantage  of  a  large  buy.  Using  the  Z-150  acquisition  approach  as  a  model,  a  contract  could  be 
let  to  procure  some  minimum  number  of  systems.  This  number  would  probably  be  quite  large, 
considering  the  various  applications  across  the  Major  Commands.  Second,  such  an  approach  could 
reduce  the  development  time  for  new  training  applications.  In  many  cases,  such  development  would 
primarily  involve  courseware.  In  those  cases  where  new  or  additional  hardware  would  be  required, 
the  existing  contract  would  provide  a  vehicle  for  hardware  acquisition,  and  courseware 
development  could  begin  immediately  on  an  existing  system  (if  available).  Third,  having  common 
hardware  throughout  the  Air  Force  would  reduce  logistics  problems.  A  single  approach  could  be 
used  for  all  systems,  even  to  the  extent  of  a  single  contract.  This  would  Increase  the 
attractiveness  of  having  support  centers  In  multiple  locations.  Including  overseas,  due  to  the 
large  number  of  systems  in  the  field.  Fourth,  the  fact  that  the  Air  Force  woulo  have  a  widely 
used  system  for  training  would  encourage  industry  standardization  compatible  with  that  system. 
With  a  large  marketplace  for  hardware/software  products  for  training.  Industry  would  no  doubt 
develop  software  packages  and  hardware  upgrades  targeted  for  the  system.  One  has  only  to 

consider  the  myriad  of  software  and  hardware  products  designed  for  the  personal  computer  (PC)  and 
Z-150  to  understand  the  power  of  having  a  focus  for  Industry  development.  One  “area"  where 

adaptation  to  a  common  CbT  system  would  be  particularly  Important  would  be  authoring  systems. 
Many  existing  authoring  systems  will  run  only  on  the  hardware  sold  by  the  particular 

manufacturer.  Having  a  conmon  system  would  encourage  manufacturers  to  adapt  their  authoring 

systems  to  this  hardware,  enabling  them  to  sell  courseware  and  courseware  development  capability 
in  lieu  of  hardware.  A  further  consideration  is  to  design  the  conmon  system  with  emphasis  on 

projected  industry  standards  to  maximize  the  supportability  of  the  system,  as  well  as  to  take 

advantage  of  existing  software  products.  Fifth,  the  use  of  common  hardware /software  would  assure 
transportability  of  courseware  across  systems  in  a  way  that  no  other  approach  will.  Again 

looking  at  the  PC  marketplace,  despite  claims  of  "PC  compatibility,’  there  are  programs  which 

will  not  run  on  PC  "clones."  In  addition,  even  those  programs  that  run  are  not  necessarily  as 
efficient  on  other  hardware,  due  to  minor  differences  in  the  architecture  of  the  systems. 

What  are  the  disadvantages  of  a  cornnon  haroware/sof tware  system?  The  primary  problem  is  the 
dependence  on  a  single  manufacturer.  This  may  be  alleviated  somewhat  if  industry  responds  by 
developing  compatible  systems.  Any  follow-on  systems  woulo  clearly  need  to  be  compatible  with 
existing  software,  to  avoid  conversion  costs.  This  could  also  result  in  source  problems, 
particularly  In  the  volatile  small -computer  Industry.  A  related  problem  would  be  the 
availability  of  systems  due  to  production  line  constraints.  Delays  in  the  delivery  of  systems 
could  have  a  domino  effect  on  the  development  times  for  new  training  applications.  Clearly,  two 
of  the  criteria  for  selection  of  a  manufacturer  woulo  have  to  focus  on  production  capability  ano 
stability. 


III.  RECOMMENDATIONS 


System  Specifications 


Considering  the  wide  range  of  possible  CbT  applications,  what  kind  of  core  system 
requirements  can  be  established?  The  following  are  some  recommended  standards  and  options  for 


such  a  system,  along  with  a  brief  discussion  of  the  basis  for  each  Item.  There  is  no  attempt  to 
make  an  exhaustive  listing;  the  Intent  is,  rather,  to  provide  representative  considerations. 

1.  Computational  Capability.  The  32-bit  CPU  is  fast  becoming  the  Industry  standard.  There 
will  be  Ada  compilers  for  32 -bit  systems,  which  will  allow  programs  developed  on  this  system  to 
comply  with  the  000  standard.  A  32-bit  system  also  allows  the  downloading  of  existing  mainframe 
computer  programs  that  may  have  training  applications.  The  system  should  obviously  include  an 
Ada  compiler.  Compilers  for  other  languages  (e.g.,  FORTRAN,  C,  Pascal)  should  be  optional,  to 
take  advantage  of  existing  programs. 

2.  Directly  Addressable  Memory.  Combining  the  32-bit  CPU  with  at  least  3  megabytes  of 
random  access  memory  (RAM)  enables  use  of  sophisticated  software  development  tools  (see  para  10), 
as  well  as  support  for  the  real-time  simulation  of  complex  systems.  The  industry  standard  for 
RAM  is  already  approaching  4  megabytes. 

3.  Graphics.  Graphics  capability  is  a  keystone  for  the  success  of  a  common  CBT  system. 
Training  of  procedures  or  situational  decision  making  require  that  the  system  present  a 
recognizable  situational  display  to  the  user.  This  may  involve  presentation  of  simulated 
instrumentation,  a  "God's-eye"  view  of  a  tactical  environment,  or  even  a  three-dimensional 
perspective  of  an  engagement,  depending  on  the  training  objectives.  To  be  effective,  the  system 
must  present  the  critical  cues  for  a  given  task  in  a  format  that  is  readily  Interpretable  by  the 
student.  This  depends  on  the  graphics  capability  of  the  system,  as  well  as  the  size  and 
resolution  of  the  monitor  on  which  the  graphics  are  displayed  (see  para  8).  In  addition,  user 
acceptance  and  system  effectiveness  are  directly  related  to  rapid  graphic  drawing  time  in 
response  to  user  Inputs.  This  capability  Is  essential  in  maintaining  fidelity  in  the  simulation 
of  systems  that  have  a  rapid  update  rate. 

There  are  several  hardware  and  software  features  which  would  aid  in  achieving  real-time 
graphics  capability.  Use  of  bit-mapped  graphics  with  double  buffering  would  be  beneficial.  With 
bit-mapped  graphics,  each  picture  element,  or  pixel,  in  a  display  has  an  associated  memory  word. 
This  information  can  be  transferred  very  rapidly  in  blocks  to  a  display-list  memory  and 
subsequently  to  the  system  that  drives  the  display  signals.  This  can  be  compared  to  vector  or 
stroke  graphics,  where  only  the  endpoints  of  each  vector  are  stored  in  memory.  The  latter 
requires  less  storage  space  in  memory  but  Imposes  a  heavy  processing  burden  at  display  time, 
slowing  graphics  response  time.  8it-mapped  graphics  require  significantly  more  memory,  but  this 
capability  is  relatively  cheap  in  today's  systems.  Double  buffering  essentially  allows  the 
system  to  have  access  to  the  data  list  for  two  displays  simultaneously.  While  half  of  the  list 
is  being  displayed,  the  other  half  is  being  rewritten  with  data  for  the  subsequent  screen 
display.  This  reduces  access  time  and,  consequently,  system  response  time.  It  is  particularly 
important  in  situations  where  animation  is  used.  Another  feature  that  facilitates  graphics  speed 
is  the  use  of  a  dedicated  subsystem  for  processing  graphics  data.  In  low-cost  systems,  this 
takes  the  form  of  a  graphics  co-processor.  In  systems  supporting  real-time,  three-dimensional 
scenes,  it  Is  usually  some  sort  of  geometry  engine.  In  both  cases,  its  purpose  is  to  remove  the 
burden  of  graphics  operations  from  the  system  CPU,  allowing  it  to  be  devoted  to  such  functions  as 
overall  program  control,  simulations,  response  monitoring,  etc. 

Given  the  key  role  of  graphics  In  many  training  applications,  program  development  time 
is  an  important  consideration  In  the  selection  of  a  system.  As  mentioned  earlier,  there  is  no 
standard  graphics  language  in  Industry,  although  attempts  to  develop  standards  such  as  the 
Graphic  Kernel  System  (GKS)  have  begun.  As  a  result,  there  are  wide  variations  in  the  graphics 
libraries  associated  with  different  systems.  Any  system  selected  as  the  common  CBT  should  have 
an  extensive  graphics  library  to  facilitate  rapid  construction  of  simulated  displays,  scenes,  and 
so  on.  This  would  benefit  users  employing  the  system's  own  graphics  library,  as  well  as 
simplifying  the  mapping  between  the  system's  graphics  calls  and  the  features  available  in  a 
resident  authoring  system  (see  para  10). 


4.  Color.  Color  Is  a  requirement  In  the  majority  of  applications.  In  part  due  to  the  need 
to  represent  the  actual  systems  faithfully.  It  may  be  convenient  to  simply  Include  color  as  a 
requirement  for  all  systems. 

5.  Souno.  The  design  of  the  system  should  make  provisions  for  inclusion  of  a  sound 
generator  to  support  presentation  of  the  audio  cues  assoclatea  with  particular  systems.  This  Is 
an  area  for  possible  growth  In  the  domain  of  speech  generation/recognition,  for  tasks  Involving 
non-scrlpteo  Interaction  with  simulated  participants  (e.g.,  a  controller).  Possible  sources  of 
pre-recorded  audio/speech  are  linear  or  still  frame  audio  from  a  videodisc  or  digitized  audio 
from  a  compact  disc. 

6.  Interface  Options.  Provisions  should  be  made  for  sufficient  serial  and  parallel  data 
ports  to  support  Interface  with  Input/output  devices  such  as  a  touch  screen,  joystick,  mouse, 
printer,  etc.  The  selection  of  devices  will  depend  on  the  application.  A  keyboard  should  be 
standard. 

7.  VI oeodl sc .  Uses  of  Interactive  videodisc  (IVD)  for  training  are  an  ever-expanding 
domain.  There  are  training  situations  where  IVD  Is  essential,  but  as  with  any  new  Instructional 
tool,  the  developer  can  become  enthralled  with  It  ano  apply  It  Inappropriately.  Videodisc 
capability  should  be  an  option  for  the  common  CBT  system,  with  Its  actual  employment  depending  on 
the  training  requirement.  The  US  Anqy  has  developed  a  standard  for  videodisc  applications  called 
the  Electronic  Information  Delivery  System  (EIDS).  The  current  design  for  EIDS  employs  the  PC/AT 
architecture,  with  special  computer  boards  added  to  handle  graphics  overlays  on  videodisc  Imagery 
and  encoding/decoding  of  still  frame  audio  and  digital  data  (e.g.,  programs)  on  the  videodisc. 
This  design  allows  for  use  of  any  standard  videodisc  player.  Interfaced  with  these  boards.  If 
compatibility  with  EIDS  Is  desired,  either  the  common  CBT  system  woulo  have  to  accept  these 
special-purpose  boards,  or  new  boards  would  have  to  be  designed  to  be  compatible  with  the  system. 

8.  Honltor(s) .  The  type  of  monltor(s)  selected  should  be  an  option  based  on  the  specific 
training  requirements,  however,  to  maintain  software  transportability,  some  features,  such  as 
bit-mapping  and  color-fill  capability,  would  have  to  be  common  across  all  systems.  Monitors 
could  vary  In  both  size  (e.g.,  13",  19",  or  large  screen  for  group  lessons/debriefing)  and 
resolution.  Monitor  size  requirements  would  be  a  function  of  factors  such  as  viewing  distance, 
legibility,  amount  of  material  presented  In  a  single  frame,  etc.  A  key  factor  In  cases  where  a 
touch  screen  Is  used  Is  to  present  controls  of  sufficient  size  to  allow  discrimination  between 
touch  points.  Differences  In  resolution  will  require  some  modifications  to  the  graphics  to 
ensure  proper  display  of  Identical  material.  In  cases  where  high-resolution  graphics  and 
videodisc  are  both  desirable,  it  may  be  advantageous  to  use  two  separate  monitors,  one 
high-resolution  Red-Green -Blue  (RGB)  and  one  National  Television  Standards  Code  (NTSC).  Current 
systems  for  displaying  video  resolution  material  on  high-resolution  monitors  are  costly.  This 
may  be  an  area  where  technological  development  will  soon  solve  the  problem. 

9.  User  Interface.  Use  of  an  Industry  standard  operating  system,  such  as  Unix,  Is 
recommended.  A  functional  standard  might  also  be  Implemented  for  a  standard  user  interface.  See 
"Standards  for  Other  Systems"  below. 


10.  Software  Tools.  Software  and  courseware  are  by  far  the  most  expensive  portion  of  any 


training  system.  In  order  to  reduce  courseware  development  costs,  software  tools  such  as 
graphics  development  packages,  programming  languages,  debuggers,  ano  script  writing  tools  should 
be  made  available.  One  approach  to  providing  these  tools  In  a  format  that  does  not  require  a 
programing  background  Is  to  supply  an  authoring  system.  These  systems  are  deslgneo  to  allow  a 
subject-matter  expert  (SME)  to  produce  courseware,  using  a  structured  format.  Morris,  Braby,  and 
Knight  (1986)  pointed  out  the  advantages  and  disadvantages  of  such  systems.  In  general,  these 
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systems  provide  effective  tools  for  efficient  generation  of  certain  types  of  courseware  and 
require  only  limited  training  to  use.  however,  they  normally  support  a  very  small  number  of 
training  formats  (e.g.,  drill  and  practice)  and  have  limited  capabilities  In  the  development  of 
system  simulations,  host  likely,  courseware  will  be  developed  through  some  combination  of  SK£ 
use  of  an  authoring  system  ano  special-purpose  programs  developed  by  programmers,  host  authoring 
systems  do  allow  branching  to  programs  developed  outside  the  system  (e.g.,  simulations).  Such  a 
combination  would  reduce  the  overall  cost  of  courseware  development  without  limiting  applications 
to  only  those  which  can  be  developed  within  the  context  of  the  authoring  system.  As  better 
authoring  tools  are  developed,  the  amount  of  Independent  programing  required  should  diminish. 


In  addition  to  courseware  authoring  capabilities,  most  of  these  systems  support  some  degree 
of  CHI .  This  Includes  such  functions  as  scoring  of  student  responses,  record  keeping,  student 
advancement  based  on  prior  performance  (adaptive  Instruction),  scheduling,  and  report 
generation.  These  functions  are  critical  for  the  training  system  manager  In  tracking  student 
progress  and  managing  training  resources.  The  extent  to  which  they  can  be  automated  directly 
affects  the  workload  of  the  Instructor s).  Any  system  proposed  for  use  with  the  common  CBT 
should  be  considered  In  terms  of  Its  Oil  functions,  as  well  as  Its  authoring  capabilities. 

One  example  of  a  courseware  authoring  and  CM  system  Is  the  Government-owned  Instructional 
Support  System  (ISS).  ISS  was  specifically  designed  to  provide  software  transportability.  In 
response  to  the  computer  proliferation  problem.  ISS  Is  modular,  enabling  portions  or  the  entire 
system  to  be  loaded  simultaneously.  This  feature  allows  ISS  to  run  on  a  variety  or  equipment, 
ranging  from  microcomputers  to  mainframes.  All  editors  In  ISS  are  menu-driven  and  require  no 
programing  knowledge  to  operate.  Minimal  training  Is  required  In  order  to  use  the  system. 
Three  main  editors  comprise  the  authoring  component  of  ISS:  Graphics  Ealtor,  Simulation  Loiter, 
and  Authoring  Editor.  This  component  allows  the  author  to  develop  Information  displays,  embedded 
questions,  ana  Inalvlduallzed  branching  paths  and  combine  them  with  graphics  ano  simulations  to 
produce  courseware.  The  editors  that  comprise  the  CMI  component  enable  the  Instructor  to 
schedule  resources  and  facilities,  set  up  shifts  ana  learning  centers,  ana  aeslgn  curricula  to 
meet  individual  needs.  Prerequisite  training,  as  well  as  acceleratlon/remedlatlon  of  Individual 
students,  can  be  deslgnea  Into  a  curriculum.  JSi  provides  automatic  assignment  processing, 
processing  and  recording  of  student  progress,  data  collection  and  analysis,  and  report 
generation.  Many  of  the  administrative  tasks  are  taken  care  of,  freeing  the  Instructor  to  spena 
more  time  with  students  on  a  one-to-one  basis.  Improvements  are  clearly  needed,  such  as  the 
inclusion  of  a  videodisc  Interface,  enhanced  tools  for  developing  task  simulations,  and  Improved 
2D  and  30  graphics  libraries.  Some  of  these  enhancements  are  already  underway.  ISS  could  be 
adapted  to  the  common  CBT  system  ana  provided  as  Government  Furnlshea  Equipment  (GFE).  As 
mentioned  earlier,  other  courseware  authoring  houses  might  find  It  beneficial  to  adapt  their 
systems  to  this  hardware  as  well.  In  which  case  such  systems  could  be  selecteo  at  the  discretion 
of  the  user. 

11.  hi  noowl ng.  Windowing  should  be  an  option,  allowing  the  system  to  continue  to  update 
"Invisible"  functions  (e.g.,  displays)  so  that  they  can  be  called  up  immediately  upon  commana. 
This  also  provides  a  means  for  declutterlng  the  display,  by  presenting  certain  Information  only 
on  demand  and  In  a  wel 1 -demarcated  portion  of  the  display. 

12.  hard  Disk.  There  Is  a  wide  range  of  options  with  respect  to  the  capacity  of  a  hard  disk 
associated  with  a  given  system.  Multiple  options  should  be  available,  again  depenoing  on  the 
training  requirement  and  based  on  complexity  of  the  programs,  size  of  data  bases  (e.g..  Defense 
Mapping  Agency  data),  etc.  In  the  case  of  Tempest-capable  systems,  the  hard  disk  must  be 
removable  for  storage.  An  alternative  medium  which  is  emerging  as  a  hlgn-oensity ,  large 
capacity  data  storage  device  Is  compact  disc  (CD).  Currently,  CD  is  a  read-only  memory  (ROM) 
device,  making  It  suitable  for  large-scale  programs  or  data  bases  that  do  not  require  frequent 
updates. 
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13.  Tempest.  Tempest  capability  should  be  an  option,  again  depending  on  the  training 
requirement.  Preferably,  Tempest  would  be  a  characteristic  of  the  system  design,  rather  than 
simply  building  a  "box"  around  the  basic  system.  A  Tempest  system  would  have  volatile  memory  and 
Include  a  removable  mass  storage  medium  (removable  hard  disk,  high-density  floppy  disk,  or  CDROM) 
small  enough  that  It  could  be  secured  In  a  typical  office  safe.  Consideration  should  be  given  to 
keeping  the  classified  materials  In  files  separate  from  the  main  program  to  simplify  management 
of  the  material. 

14.  Networking.  For  some  applications.  It  might  be  appropriate  to  network  a  number  of 
Individual  delivery  stations  to  a  CPU,  disk  server,  etc.  This  type  of  option  would  be  most 
advantageous  in  a  "school house"  setting,  where  a  high-capability,  stand-alone  system  may  not  be 
necessary  or  even  desirable.  Most  of  the  systems  on  the  market  have  some  provision  for  Ethernet 
or  some  equivalent.  This  should  be  a  requirement  for  the  system. 


Standards  for  Other  Systems 

For  those  cases  where  the  user  decides  not  to  use  the  common  CBT  system,  we  are  still  faced 
with  the  problem  of  training  users  to  interact  with  each  of  the  different  systems.  One  approach 
to  this  particular  problem  would  be  to  develop  standards  for  the  structure  of  the  user  Interface, 
so  that  the  user  could  expect  to  work  with  the  same  basic  displays  and  commands  in  each  case. 
This  would  Include  standards  for  structuring  of  menus.  Icons,  definition  of  particular  character 
strings,  log-on  procedures,  etc.  These  standard  formats  would  then  lead  the  trainee  Into  the 
more  specific  control  structure  of  a  given  training  program.  This  Is  an  area  for  further  study, 
to  develop  an  optimal  standard  and  consider  the  feasibility  of  its  Implementation. 

Although  the  development  of  standards  for  the  user  Interface  would  address  the  training 
Issue,  It  would  not  solve  the  problem  of  courseware  transportability  across  systems.  A  possible 
approach  to  this  problem  would  be  to  develop  a  virtual  machine  Interface  { VMI } .  The  VMI  would  be 
a  set  of  standards  for  high-level  calls  to  perform  a  given  function.  For  example.  In  the  area  of 
graphics,  there  would  be  a  standard  call  to  place  a  circle  on  the  display  monitor  in  a  certain 
position  (e.g. ,  by  specifying  a  circle  function  with  Its  associated  attributes,  such  as  a  center 
point  and  a  radius,  filled  with  a  particular  color,  etc.).  Each  hardware  system  would  have 
specific  Interpreters  In  software/firmware  to  translate  this  call  into  Its  unique  function(s)  for 
producing  the  appropriate  response.  This  would  allow  courseware  from  the  common  CBT  system  to 
run  on  other  systems.  However,  It  would  require  significant  effort  for  each  system  to  develop 
the  machine-specific  software/firmware  to  provide  the  VMI.  In  addition,  this  type  of  approach 
does  not  address  the  acquisition  and  logistics  Issues  which  a  common  contract  does. 

A  final  area  for  consideration  of  standards  is  In  the  area  of  authoring.  As  mentioned 
earlier,  It  Is  likely  that  authoring  system  vendors  will  find  it  advantageous  to  make  their 
software  compatible  with  the  common  CBT  system.  This  would  allow  users  to  take  advantage  of  a 
variety  of  authoring  systems.  However,  this  complicates  matters  when  a  particular  user  wishes  to 
employ  courseware  developed  on  a  "foreign"  authoring  system.  There  are  several  levels  at  which 
the  user  might  wish  to  Integrate  this  "Imported"  courseware  Into  existing  courses.  At  the  least 
complex  level,  there  would  probably  be  little  problem  If  all  that  was  desired  was  to  run  a 
compiled  lesson  from  this  other  system.  The  situation  becomes  more  complex  at  a  second  level 
where  the  user  wishes  to  tie  this  lesson  into  an  existing  CMI  capability.  This  would  require  the 
Imported  courseware  to  provide  standard  outputs  (e.g.,  percent  correct,  time  on-task)  in  a 
recognizable  format.  This  Implies  establishing  standards  for  data  streams  which  could  be  read  by 
the  CMI  function  of  any  system.  The  most  complex  level  arises  when  the  user  wishes  to 
Incorporate  portions  of  an  Imported  lesson.  To  do  this  would  require  that  the  various  authoring 
systems  have  common  data  formats  for  graphics,  text,  video  control,  etc.  This  would  allow  the 
host  authoring  system  to  read  the  Imported  courseware  and  pull  out  the  necessary  material.  This 
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would  mean  that  there  would  have  to  be  standardized  data  formats  for  text  ana  graphics  files,  as 
there  Is  now  for  videodisc  Imagery.  This  Is  clearly  an  area  requiring  further  study,  to 
determine  the  costs  and  benefits  of  achieving  compatibility  at  these  three  levels. 


Future  Developments 

One  of  the  current  problems  In  the  development  of  CBT  systems  Is  the  limited  availability  of 
expertise  In  the  area  of  Instructional  design.  In  many  cases,  SMEs  are  used  In  the  design  of 
courseware.  This  Is  beneficial  In  terms  of  making  sure  that  the  content  of  the  courseware  Is 
valid,  but  such  personnel  are  usually  unschooled  In  Instructional  techniques  ana  approaches. 
Current  authoring  systems  are  generally  designed  to  be  "user  frlenaly,"  but  It  takes  some  time  to 
train  SMEs  how  to  use  them.  Even  when  the  SMEs  are  trained,  those  systems  that  provide  options 
In  Instructional  format  require  some  juogment  on  the  part  of  the  SME  to  determine  which  approach 
Is  most  appropriate.  There  Is  also  a  tendency  for  the  SME  to  become  "enthralled  with  the  tool" 
and  to  apply  It  In  cases  where  other  media  may  be  more  suitable.  Since  It  Is  unlikely  that  the 
pool  of  Instructional  design  personnel  Is  likely  to  grow  significantly,  two  options  for 
addressing  the  problem  appear  viable.  One  approach  Is  to  use  CBT  Itself  to  "train  the  trainer" 
In  Instructional  techniques;  that  Is,  to  use  CBT  to  train  SMEs  In  Instructional  design  as  well  as 
in  the  use  of  a  particular  authoring  system.  This  type  of  training  would  be  a  logical  adjunct  to 
existing  authoring  systems.  The  second  approach  Is  to  develop  more  Intelligent  authoring  tools, 
which  require  the  SME  to  supply  only  the  expert  knowledge  on  which  the  courseware  Is  based.  The 
system  Itself  would  then  "decide"  what  the  proper  format  and  sequence  of  Instruction  should  be. 
Such  systems  would  reduce  development  time  and  obviate  the  need  for  training  SMEs  In 
instructional  design.  Both  of  these  options  should  be  pursued.  Use  of  CBT  to  train  SMEs  coula 
provide  a  short-term  solution  while  the  data  bases  and  systems  are  being  developea  to  provide 
Intelligent  authoring  In  the  long  term. 

The  development  of  Intelligent  authoring  tools  Is  merely  one  aspect  of  the  more  general 
attempt  to  apply  artificial  Intelligence  (AI)  techniques  to  CA1.  Intelligent  CAI  (ICAI)  Is  a 
rapidly  expanding  area,  where  tools  such  as  Intelligent  tutors,  expert  and  student  models,  and 
authoring  aids  are  being  Investigated.  If  ICAI  Is  to  be  successfully  applied  to  systems  such  as 
the  common  CBT  system,  one  of  the  keys  will  be  the  development  of  the  necessary  tools  for  this 
type  of  hardware.  The  majority  of  AI  work  is  currently  done  on  systems  specially  designed  for 
symbolic  processing  using  languages  such  as  LISP  and  SN0BCL4.  However,  rapla  developments  within 
the  microcomputer  Industry,  In  terms  of  computational  capability  and  virtual  memory,  have  made  It 
feasible  to  do  AI  programming  on  low-cost  hardware  (Richardson,  1963).  In  addition,  recent  work 
has  demonstrated  the  capabilities  of  Ada  for  use  In  AI  programming  (Reeker,  Kreuter,  A  Vlauchope, 
1985).  The  latter  development  Is  particularly  Important  for  any  common  CBT  system,  as  It  would 
allow  a  single  language  to  be  used  for  the  entire  spectrum  of  applications.  In  this  way,  ICAI 
could  be  Integrated  with  existing  systems,  rather  than  requiring  separate,  special-purpose 
hardware. 

A  final  area  of  future  concern  Is  the  Interface  between  CBT  and  flight  simulators.  The  issue 
here  Is  the  use  of  common  software,  or  even  hardware,  to  support  system  simulation  for  part-task 
and  simulator  training.  There  are  ongoing  programs  Investigating  the  possibility  of 
"modularizing"  simulators;  that  Is,  developing  distinct  modules  to  control  particular  portions  of 
the  simulation.  Some  of  these  modules,  such  as  those  for  specific  avionics  systems,  could  be 
Implemented  on  microcomputer  systems  operating  In  a  distributed  processing  network.  These 
modules  would  be  relatively  Independent,  to  allow  updates  to  Individual  programs  without 
disrupting  the  overall  simulation.  The  same  programs  used  In  these  modules  could  be  Incorporated 
Into  the  common  CBT  system  to  provide  real-time  task  simulation  for  procedures  training.  The 
Interface  requirements  woula  differ,  but  the  basic  task  simulation  would  be  Identical.  This 
would  have  the  benefit  of  ensuring  compatibility  between  the  simulator  and  the  part-task 


trainer.  In  addition,  changes  to  the  programs  to  reflect  aircraft  modifications  would  be 
simultaneously  implemented  on  the  two  systems.  Whether  this  commonality  would  extend  Into  the 
hardware  domain  depends  on  engineering  design  considerations.  The  fact  that  future  simulators 
will  be  designed  to  use  Ada  provides  additional  Impetus  to  the  use  of  Ada  on  the  common  CBT 
system. 


IV.  SUMMARY 

This  paper  considers  the  feasibility  of  the  concept  of  a  common  CBT  system.  We  believe  that 
an  approach  modeled  after  the  Z-150  acquisition  could  make  some  Inroads  In  solving  the  problems 
of  computer  proliferation,  compatibility,  transportability,  etc.  Clearly,  any  such  system  must 
be  designed  for  training,  although  It  may  have  applicability  In  other  domains  (e.g.,  operational 
aids).  Some  recommended  capabilities  have  been  presented,  although  the  system  should  be  modular 
so  that  the  design  can  be  adapted  to  specific  training  applications.  This  is  not  intended  to  be 
the  final  word  but  rather,  a  starting  point  for  further  discussion. 
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